|
|
| Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Tonto Auri
Vhero' Multipurpose Corp
   |
Posted - 2010.10.13 16:10:00 -
[1]
How much more cumbersome the everyday extractors setup will become with this change?
Did you resolved the issue with processors locking goods out of processing?
--
Thanks CCP for cu |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.13 17:12:00 -
[2]
Edited by: Tonto Auri on 13/10/2010 17:13:22
 Originally by: CCP Tuxford
We fiddled around with the routing so it attempts to automatically route products even though it isn't getting the same amount from newly installed program.
Want an advice? Get rid of the routing amount in route definition, it's senseless.
Quote:
I'm not familiar with the issue you're describing unless it's the issue where processors weren't being started when stuff was moved to a spaceport/command center. That has been fixed and deployed to TQ shortly after Tyrannis 1.1.
Issue is simple:
Let's say, I have two processors making Mechanical Parts (Precious+Reactive) and Enriched Uranium (Toxic+Precious) respectively.
The current logic is: Receive a batch of goods, empty storage, start production, deliver the result.
Seems good et all, until you hit the situation, where last batch of Precious metals gets routed to Mechanical Parts, and last batch of Toxic Metals gets routed to Enriched Uranium. And both processors sitting idle staring at eachother, neither have anything to do from now on.
The neighbouring issue is when you want to roll up your network, you need to wait up to two hours before you can actually cease all operations.
But with a small change in chain, it would radically reduce the hassle.
Just make it "Get materials - start processing - empty storage - deliver the results". Or, "* - deliver the results - empty storage", if you want even more fool-proof with protection from cut supply lines. If result can't be delivered (no route to host, ahha), the processor will skip to the next cycle without emptying it's storage.
Will also solve the rollup issue - you'll only need to wait for all current cycles to end - less than an hour in either case.
--
Thanks CCP for cu |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.14 15:00:00 -
[3]
Originally by: Aeo IV
Could we have some sort of system to transport materials between storage units, without using ex. transfers?
And you need it - for?
--
Thanks CCP for cu |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.14 20:20:00 -
[4]
Edited by: Tonto Auri on 14/10/2010 20:21:38
Originally by: Beani Kliadi
Really like this, as of writing this im going through all my extractors n surveying. These changes will give me alot more gaming time in the evenings with my corp mates.
Don't be so sure. Last time I checked the new extractors UI, it was hell of a frustration. I gave up after 30 or 40 min trying to figure it out. Can't check it now as the CC seems to be not seeded.
P.S.
Regarding CC's, separation to Barren/Terrain/Ocean/Whatever CC was a mistake, IMO. Cluttering design without clear advantage by any means.
--
Thanks CCP for cu |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.16 01:47:00 -
[5]
Edited by: Tonto Auri on 16/10/2010 01:50:59
Well, thanks for seeding CC's... now, when I got the feeling of it (finally, to say), I have to say, that 10/90 principle is a good excuse (and a nice joke) for lazy programmer, but villingly implement it in program (in GAME!) is a bad design decision. VERY bad.
http://yfrog.com/ml20101016013121j
The first peak, when extractors yield are fixed, would overload even upgraded links, when the 90% of the time the money spent on link upgrades would be totally useless.
There was already a suggestion to use CPU/PG duality to control throughput. Define link length by powergrid and control links throughput by CPU remaining (exponentially increase CPU load for higher throughput). Upgrading link will increase PG usage slightly and flatten the throughput/CPU curve.
--
Thanks CCP for cu |
|
|
| |
|